IBIS Macromodel Task Group Meeting date: 18 April 2017 Members (asterisk for those attending): ANSYS: * Dan Dvorscak * Curtis Clark Broadcom (Avago): Xingdong Dai * Bob Miller Cadence Design Systems: Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas Marc Kowalski Ericsson: Anders Ekholm GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: Fangyi Rao * Radek Biernacki Ming Yan Maxim Integrated Products: Hassan Rafat Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: * Randy Wolff Justin Butterfield QLogic Corp.: James Zhou Andy Joy SiSoft: * Walter Katz Todd Westerhoff * Mike LaBonte Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross TI: Alfred Chong The meeting was led by Arpad Muranyi. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - None. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: - Arpad: Does anyone have any comments or corrections? [none] - Walter: Motion to approve the minutes. - Dan: Second. - Arpad: Anyone opposed? [none] ------------- New Discussion: BIRD 186.2 File Naming Rules: - Walter: Currently IBIS limits file names to 40 characters. - As part of this BIRD we introduced relative paths to file name quantities. - Therefore, we wanted to increase that 40 character limit. - We considered various values and settled on 256 characters. - A colleague of mine recently reminded me that for the Windows OS 256 characters is the hard limit on the total path (e.g. C:\....). - Therefore the 256 character limit in BIRD 186.2 is impractical. - The location of an IBIS library directory where an IBIS file lives might easily be 30 or more characters itself. - What should we reduce it to? - There are several solutions. I'm leaning toward just reducing it to 64 or 128 characters. That way the EDA tool knows how long the path to its library directory could be before it risks running into an OS limit. - Arpad: The original 40 character limit was for the file name itself (no path). - So 64 would seem too low a limit if the quantity includes a relative path. - Radek: There are two cases: - 1. [File Name] keyword contains only the file name itself (no path). For that one name, 64 would be more than enough. - 2. For quantities that include the path we might only be able to issue a caution for the user. Even a short path used by the EDA tool to store a library might lead to an extremely long absolute path when everything is combined. - Arpad: Are we talking about a limit on the file name itself or relative path? - Walter: As the BIRD is written, it is the limit on the combined file name and relative path from the directory containing the IBIS file. - Radek: In that case 128 is a reasonable limit, and we may still need a caution. - Bob R.: We should use 128 as a limit, but explicitly state that the file name itself, as would appear in the [File Name] keyword, is limited to 64. - Walter: Agreed. I'll create a 186.3 draft 1 incorporating Bob's suggestions. - I'll email it to the group and we can review the text via email. BIRD 166.1 Redriver Init() Flow Improvements: - Walter: I came up with a slight change to my original proposal and sent it out recently. (see previous meeting minutes) - It precisely solves the redriver Init() flow problem by allowing the redriver Tx to see the right IR in case it needs to optimize itself. - The proposal now solves the redriver Init() flow problem with minimal text modifications to the spec. - Fangyi still objected based on the crosstalk issue. - I've recently sent him an email and am waiting for his response. - I think that's an independent issue. - I will submit this proposal to the Open Forum. If there's good support there we can move forward. - Arpad: I also forwarded your email to Vladimir. - Fangyi also raised a question about multiple (cascaded) redrivers. - Walter: I think that was a non-issue. - The flow I'm proposing works fine. You take every bit of upstream equalization and keep accumulating it. That's all my BIRD says. - If Fangyi really objects, and I don't get support in the Open Forum, then we may just reject BIRD 166.1. - Arpad: So, the only issue is crosstalk? - Walter: Yes, crosstalk was fundamentally wrong from the beginning. - To correct it you must have the model somehow return the part of the equalization that affects crosstalk. - The Tx model's Init() should return the Tx equalization, and the Rx model's Init() should return the Rx equalization in two parts (LTI part and the non- LTI part). - Fangyi is doing the right thing adding additional outputs to the Rx Init(). - He should also add an additional output to the Tx Init(). - That will solve the crosstalk issue, and it's independent of my BIRD 166.1. - Arpad/Curtis: What about the issue you raised last week with DDR5 and the Tx optimizing the Rx? Do we have a problem with the fact that we always call Tx AMI Init() first? - Walter: BIRD 147 (back channel) could handle that. The BCI protocol could call for the Tx Init() to write something to Rx Init(), even though BIRD 147 currently only allows the iterative calls in GetWave(). The protocol could allow the Tx to optimize the Rx during GetWave(). The protocol could even deal with the subtle issue that in BIRD 147 only the Rx can terminate the training. - Bob R.: I have no problem updating BIRD 166 with this proposal, which is a simpler version anyway. - I still have concerns about whether agreement on technical content will hold up approval. - I still have concerns about whether a more advanced version would have any conflicts with this one. - Walter: If I'm going to go through the extra effort of changing my proposal to deal with the additional information in the IR matrix, then I want to do it once and do it right. - What Fangyi is proposing is itself incomplete in that it doesn't handle the Tx that wants to optimize itself. - In the meantime we have a fundamental issue where the basic flow in the standard is incorrect. - We should fix that fundamental flaw so we don't have tools generating different answers because one follows the flow in the spec. and one does it the right way. - Crosstalk is a flaw at another level. - Radek: The problem I see with BIRD 166.1 is that if we just go with it we may end up in a place where we can't get to the crosstalk solution. - BIRD 166.1 is no doubt an improvement over what's in the spec. now. - But it is something of a small hack at this point. - We may have to undo this approach to get to the final crosstalk solution. - Walter: The input to the downstream Rx is the same in my flow as in Fangyi's. - Fangyi's flow adds two additional outputs to the Rx Init(), but they are not used for the main channel they're used for crosstalk. - To fully solve the crosstalk problem, you also need to get the IR of the Tx equalization. That is what affects crosstalk from the upstream channel. - Since Fangyi's BIRD is independent, we should put all the effort into getting that one right all at once to solve the crosstalk problem. - Radek: I see the improvement from BIRD 166.1. - But users don't want to hear that "we don't support that crosstalk case." - Arpad: We have a flow problem, and we have a crosstalk problem. - Walter's BIRD 166.1 can fix the flow problem. - It doesn't fix crosstalk, but crosstalk is separate and the fix can be added later, right? - Radek: The crosstalk fix may not be additive. - Walter: If Keysight and others feel this way, then BIRD 166.1 will be tabled and won't get into the next release of the spec. But we know tools should take note of the fact that the flow in IBIS 6.1 is wrong. BIRD 158.4 - AMI Ts4file Analog Buffer Models: - Walter: We deferred any vote in the Open Forum waiting for a recommendation from ATM. - Bob R.: We would have to upload BIRD 158.4. - Radek: We have the BIRD 158.4 draft 4 that I sent out right before the meeting two weeks ago. We haven't had a chance to discuss it yet. - Radek: [sharing the draft] - I got good feedback from Arpad, Bob R., and Bob M. and incorporated it. - I would like to get some from Ambrish since I added some phrases at his request. - But we could go ahead and make a recommendation without his feedback. - There are some changes to the schematics. - "buffer terminals" in the Tx and Rx schematics (from Arpad's suggestion). - "By definition, the placement of the Ts4file information within the .ami file makes the Ts4file data exclusively limited to AMI applications..." (paragraph added at Ambrish's request). - New Ts4file_Includes parameter (Bob Miller's suggestion) - Allows the model maker to tell the world what is included in the Touchstone file. - This can give the user the information on what the boundaries are for the "User Setup" block shown in the schematic. - We don't say anything about reusing legacy data. We don't want to. The point is that this BIRD bypasses the IBIS file entirely for the analog model. - Editorial Corrections Noted: Bob Ross pointed out that all instances of should have a lower case "s" in string. Bob Miller pointed out that the allowed values for Ts4file_Includes are "buffer", "pad", and "pin" (not "package"). Radek agreed with these corrections and made the changes. - Walter: I move that we make a recommendation to the Open Forum to approve BIRD 158.4. - Bob M.: Second. - Arpad: Anyone opposed? [none] - Mike L.: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Walter to send a BIRD 186.3 draft 1 to the ATM for review. AR: Walter to send BIRD 166.1 to Mike L. to be posted as a BIRD on the Open Forum site. AR: Radek to send BIRD 158.4 (with the editorial changes from the meeting) to Mike L. to be posted to the ATM archives as BIRD 158.4 draft 4 and to be posted to the Open Forum site as BIRD 158.4. ------------- Next meeting: 25 April 2017 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives